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1.0  INTRODUCTION 


This  chapter  explains  the  purpose  of  the  convention,  and  the  scope 
of  the  guidance  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implementation 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  X12  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  on 
information  interchange  procedures  that  require  the  collection, 
reporting,  and/or  exchange  of  data  needed  to  perform  defense 
missions. 

1.2  SCOPE 

The  guidance  presented  here  may  be  used  by  organizational  ele¬ 
ments  of  the  DoD  community  and  by  non-DoD  organizations  that 
exchange  data  with  the  DoD  community  in  the  course  of  their 
business  relationships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components). 

Non-DoD  organizations  include  (a)  non-Govemment  organiza¬ 
tions,  both  commercial  and  nonprofit;  (b)  Federal  agencies  of  the 
United  States  Government  other  than  DoD;  (c)  local  and  state 
governments;  (d)  foreign  national  governments;  and  (e)  interna¬ 
tional  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology),  Com¬ 
puter-aided  Acquisition  and  Logistics  Support  and  Electronic  Data 
Interchange  [OUSD  (A  &  T)  CALS/EPI]  their  data  requirements 
that  are  not  covered  in  this  convention  as  soon  as  possible,  as 
indicated  in  Chapter  2.0,  Section  2.1. 

1 3  RESPONSIBLE  ENTITY 

{Reserved} 

1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
EDI  Implementation  Reference  Manual  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
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agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  this  document  and  are  defined  as  follows: 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  XI 2  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12;  specifically,  transaction  sets,  segments,  data  ele¬ 
ments,  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4.1 .1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  by  business,  technical,  and 
EDI  ASC  X12  standards  experts.  The  business  data  requirement 
is  defined,  a  transaction  set  is  selected,  and  the  data  requirement 
is  then  identified  with  data  elements  in  the  transaction  set.  A 
convention  is  usually  developed  before  any  computer  EDI  systems 
development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1 .4.1.2  Why  Use  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  X12  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  that  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1.4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  programmers  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  XI2  transaction  set. 

1 .4.4.4  Can  1  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  CALS 
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Evaluation  and  Integration  Office.  See  Chapter  2.0,  Maintenance, 
Section  2.1  for  the  point  of  contact. 

1.4.2  Documentation  of  Conventions 

Conventions  are  adopted  from,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  table.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  XI 2  standards  manual  is  presented  on  the  right  side 
of  the  page.  That  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U”  stands  for  “not  used”  and  appears  in  the 
left  column  if  DoD  does  not  use  the  specific  segment.  A  page 
number  will  appear  if  the  segment  is  used. 

1. 4.2.2  Transaction  Set  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  spec  fied  on  the  left  side  of  the  page.  For  identifier 
(ID)-type  data  elements,  acceptable  code  values  are  listed  on  the 
right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  right  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  X12  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  are  defined  by  ASC  XI 2. 

•  Optional 

Optional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
partners. 

•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
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010 


10  010 
12  020 
13  030 

N/U  040 
N/U  050 
N/U  060 


14  070 

15  080 

16  090 


This  standard  provides  the  format  and  estaDiishes  the  data  contents  ot  the 
Application  Advice  Transaction  Set  (824)  within  the  context  ot  an  Electronic 
Data  interchange  (EDI)  environment  This  transaction  set  provides  the  ability 
to  report  the  results  ot  an  application  system  s  data  content  edits  ot 
transaction  sets  The  results  ot  editing  transaction  sets  can  be  reported  at  the 
functional  group  and  transaction  set  level,  m  either  coded  or  tree-form  format 
it  is  designed  to  accomodate  the  business  need  ot  reporting  the  acceptance, 
rejection  or  acceptance  with  change  ot  any  transaction  set.  The  Application 
Advice  should  not  be  used  in  place  ot  a  transaction  set  designed  as  a 
specific  response  to  another  transaction  set  (e  g.,  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 
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Figure  1.4-1  Example  of  a  Transaction  Set  Table 


DEPARTMENT  OP  DEFENSE 
DRAFT  M  PIGMENTATION  CONVENTION 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


(34  -  APPLICATION  ADVICE 
BON  •  BEGINNING  SEGMENT 


ANSI  A  SC  X13  VERSXM4IRELEASE003010000 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Conditional 


Not  Good 


Segment: 

LdVdl: 

Loop: 
Usaga: 
Max  Usa: 


BGN  Baginning  Sagmant 
Header 


Mandatory 
1 

Purpose:  To  indicate  the  beginning  of  a  transaction  set 
Syntax:  If  BGNOS  is  used.  BGN04  is  required 
Comments:  I.  BGN02  is  the  Transaction  Set  Reference  Number 

2.  BGN03  is  the  Transaction  Set  Date 

3.  BGN04  is  the  Transaction  Set  Time 

4.  BGN05  is  the  transaction  set  time  qualifier 
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Figure  1.4-2  Example  of  a  Transaction  Set  Segment 
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their  use  to  facilitate  EDI.  Most  companies  in  the  industry 
are  expected  to  use  this  data  element. 

•  Not  Used 

“Not  Used”  data  elements  are  those  that  DoD  does  not  use 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 

This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions.  It  also  presents  a  section  on  version/release  timing 

2.1  MAINTAINING  CONVENTIONS 

(Reserved} 

2.2  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  12-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480,  Ver¬ 
sion/Release/Industry  ID.  This  12-character  code  is  used  by 
A  SC  X12  as  follows: 

Position  Content 

1-3  Version  number 

4-5  Release  level  of  version 

6  Subrelease 

7-12  DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  Positions  1  through  6. 

The  version  number  (001,  002,  003,  etc.)  will  change  only  after  an 
official  public  review  cycle  leads  to  republication  of  a  new 
American  National  Standard. 

The  release  level  of  each  new  major  version  (Positions  4-6  in  the 
Functional  Group  Header)  will  begin  at  “000”  and  increased  by  1 
for  each  new  ASC  XI2  approved  publication  cycle,  usually  once 
a  year.  The  fourth  and  fifth  characters  designate  the  release  and 
the  sixth  character  designates  the  subrelease. 

The  DoD  Industry  Trade  Association  ID  (Position  7-12)  is  used 
to  identify  conventions.  For  this  suffix,  DoD  will  use  “DoD_” 
with  the  10th  character  identifying  successive  publications.  The 
1 1th  and  12th  characters  may  be  used  by  the  Military  Departments 
or  Defense  agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
by  the  OUSD  (A  &  T)  CALS/EDI. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 

This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes 

3.1  INTRODUCTION 

The  power  of  the  ASC  XI 2  standard  is  in  its  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  The  concept  is  analogous  to  a  "standard  bill  of 
materiels  and  the  construction  specifications,”  which  gives  the 
architect  flexibility  in  what  can  be  designed  with  standardized 
materiels  and  procedures.  The  EDI  system  designer,  like  the  ar¬ 
chitect,  uses  the  ASC  X12  standards  to  build  business  transactions 
that  are  often  different  because  of  their  function  and  yet  utilize  the 
ASC  X12  standards.  The  “bill  of  materiels  and  the  construction 
specification”  of  ASC  XI 2  are  the  standards  found  in  the  published 
technical  documentation. 

ASC  X12.3  -  The  Data  Element  Dictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
•he  transaction  sets  developed  by  ASC  XI 2. 

ASC  XI 2.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  header 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provides  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X  12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  X12. 

The  DoD  convention  in  Section  3.4  conforms  to  the  above  stand¬ 
ards,  and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technical  documentation.  For 
copies,  contact  either  the  OUSD  (A  &  T)  CALS/EDI  or  the  Data 
Interchange  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  control  segments 
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designed  to  identify  uniquely  the  start  and  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3.2-1.  Control  Segment 
specifications  are  defined  in  Section  3.2.2. 

Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  «,.'ntrol  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  separators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknowledgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TA1  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  acknowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  functional  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Figure  3.2-1.  Hierarchical  Structure 


BASELINE  AS  OF:  JULY  9, 1993 


3.0.3 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REQUEST 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 

_ ANSI  ASC  X12  VERSION/RELEASE  003030DQD_ 

3.2.2  Control  Segment  Specifications 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 
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DEPARTMENT  OF  DEFENSE 
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Mandatary 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments 

Data  Element  Summa 


REP  DATA 

DES.  ELEMENT  NAME  _ 


ISA01  101  Authorization  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Information  in  102) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

ISA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 


ISA06 


ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  ( DoDAAC )  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA06  106  Interchange  Sena  >0  M  ID  15/15 

Identification  code  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  IS  AOS  and 
coordinated  with  the  VAN. 

ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 


BASELINE  AS  OF:  JULY  9, 1993 
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Mandatory 


Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC )  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA08  107  Interchange  Receiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parlies  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


ISA09  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

ISA  10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

ISA  11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  the  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

ISA  12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00303  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  XI 2  Procedures 
Review  Board  Through  October  1992 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 


Mandatory 


ISA13 


Mandatory  ISA14 


Mandatory  ISA15 


112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  ‘.he  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 


Dll  9-  3.0.8 
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Code  Value  Implementation  Note: 

Assigned  by  translation  software. 


001  •  CONTROL  SEGMENTS 

ISA  •  INTERCHANGE  CONTROL  HEADER 


Mandatory 


ISA16  115  Subelement  Separator  M  AN  1/1 

This  is  a  field  reserved  for  future  expansion  in  separating  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 


BASELINE  AS  OF:  JULY  9, 1993 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  XI 2 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

(ICF.  OATA 

DCS _ CLEMENT  NAME _ ATTHtMUTCS 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  content  of  the  functional  group.  See  XI 2  Dictionary  for 
source  code  list. 

SP  Specifications/Technical  Information  (841) 

GS02  142  Application  Sender's  Code  M  AN  2/15 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  1SA06. 


Mandatory 


GS03  124  Application  Receiver’s  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA08. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


GS04 

373 

Date 

Date  sender  generated  a  transaction  set. 

M 

DT 

6/6 

GS05 

337 

Time 

Time  expressed  in  24-hour  clock  time. 

M 

TM 

4/6 

GS06 

28 

Group  Control  Number 

Assigned  number  originated  and  maintained  by  the  sender. 

M 

NO 

1/9 

Implementation  Note: 

Assigned  by  translation  software. 

GS07 

455 

Responsible  Agency  Code 

M 

ID 

1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 


X  Accredited  Standards  Committee  XI 2 


Dll 9  •  3.0.10 
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GS  •  FUNCTIONAL  GROUP  HEADER 

Code  Value  Implementation  Note: 

Indicates  that  an  ANSI  1  standard  is  being  transmitted. 


841  REQUEST 
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Mandatory 


GS06  480  Version/Release/Industry  ID  Code  M  ID  1/12 

Code  indicating  tne  version,  release,  subrelease  and  industry  identifier  of  the  EDI 
standard  being  used.  Positions  1-3,  version  number;  positions  4-6,  release  and 
subreleas6  level  of  version;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 

003030  Draft  Standards  Approved  by  ASC  X12  Through  October  1992. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  See  XI2  Dictionary  for  source  code  list. 


BASELINE  AS  OF:  JULY  9, 1993 
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001  •  CONTROL  SEGMENTS 
GE  •  FUNCTIONAL  GROUP  TRAILER 


Mandatory 


Mandatory 


Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 

Data  Element  Summa 


GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 

GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 


DI19  •  3.0.12 


BASEUNE  AS  OF:  JULY  9, 1993 
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Segment:  IEA  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

REF  DATA 

PCS. _ ILEMEHT  MAJAC _ ATTIHPLnES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  try  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  number  that  occurs  in  ISA13. 


BASELINE  AS  OF:  JULY  9, 1993 
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EXAMPLE  -  SPECIFICATIONS/TECHNICAL  INFORMATION 
841  TRANSACTION  SET  (REQUEST) 


ASC  X12  EDI  FORMAT  DEFINITION 

ST*84 1*00001  n/1  This  is  an  841  transaction  set  with  a  control  number  of  00001. 

SPI*92*TN*841REQ001****13*DW*02  Data  requested  are  classified  government  confidential  (Code 
n/1  92).  The  transaction  set  reference  number  (Code  TN)  is 

841REQ001.  This  is  a  request  (Code  13)  for  drawings  (Code 
DW).  The  requested  data  have  a  commercial  security 
protection  requirement  of  company  confidential  (Code  02). 


REF*KS*N0001993Q2468  n/1 

DTM*993*930615  n/1 
REF*TN*841REQ001  n/1 

DTM*097*93O7Q7  n/1 
REF*ZZ*RFQ2468  n/1 

DTM*368*930616  n/1 

N1*FR**33*B1234  n/1 

N1*BY**10*N00019  n/1 


The  solicitation  number  (Code  KS)  to  which  the  requested 
data  pertain  is  N0001993Q2468. 

The  date  of  the  solicitation  (Code  993)  is  June  IS,  1993. 

The  unique  reference  number  of  this  transaction  set  (Code 
TN)  is  841REQ001. 

The  date  of  this  transaction  set  (Code  097)  is  July  7, 1993. 

The  unique  reference  number  (Code  ZZ)  of  the  transaction  set 
to  which  this  request  pertains  is  RFQ2468. 

The  date  of  the  referenced  transaction  set  (Code  368)  is  June 
16, 1993. 

This  request  is  from  (Code  FR)  a  company  whose  CAGE  code 
(Code  33)  is  B1234. 

The  buying  activity's  (Code  BY)  DoDAAC  is  N00019. 


PER*IC*Tom  Cruise*EM*EMTW12579  The  point  of  contact  (Code  IC)  at  the  requester's  facility  is 
n/1  Tom  Cruise.  His  electronic  mail  address  (Code  EM)  is 

EMTW12579. 


HL*1**A*1  n/1  This  is  the  first  iteration  of  the  HL  segment  as  specified  by  the 

number  1.  It  has  no  parent  The  hierarchical  level  is  the 
assembly  (Code  A).  It  has  a  child  (Code  1). 

SPI*92*DG*12E2211******02  n/1  The  requested  drawing  (Code  DG)  number  is  12E2211.  It  is 

classified  government  confidential  (Code  92)  and  has  a 
commercial  security  protection  requirement  of  company 
confidential  (Code  02). 

RDT*E*ALL  n/1  All  drawing  revisions  (Code  E)  are  being  requested  (indicated 

by  the  word  "ALL"). 
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Ml  •  REQUEST 


UN**FS*1680010839*PD*Panel,  Ground  The  national  stock  number  (Code  FS)  of  the  assembly  is 
Check  n/1  1680010839.  The  item  description  (Code  PD)  is  Panel,  Ground 

Check. 


HL*2*1*U*1  n/1  This  is  the  second  iteration  of  the  HL  segment  as  specified  by 

the  number  2.  Its  parent  is  HL  1.  The  hierarchical  level  is  the 
subassembly  (Code  U).  It  has  a  child  (Code  1). 


SPI*92*DG*H12D4fl8-30******02  n/1 

RDT*E*A  •007*910220  n/1 

L1N**PD*  Wiring  Harness  n/1 
HL*3*2*I*0*  n/1 

SPI*90*S3*Z-R701  n/1 

RDT*H*  As*Built  n/1 
HL*4*1*U*1  n/1 

SPI*90*DG*12E2213******06  n/1 

RDT*E*Latest  n/1 


The  requested  drawing  (Code  DG)  number  is  H12D408-30.  It 
is  classified  government  confidential  (Code  92)  and  has  a 
commercial  security  protection  requirement  of  company 
confidential  (Code  02). 

Revision  (Code  E)  "A"  with  an  effective  date  (Code  007)  of 
February  20, 1991  is  requested. 

The  item  description  (Code  PD)  is  Wiring  Harness. 

This  is  the  third  iteration  of  the  HL  segment  as  specified  by 
the  number  3.  Its  parent  is  HL  2.  The  hierarchical  level  b  the 
hem  (Code  I).  It  has  no  child  (Code  0). 

The  requested  specification  (Code  S3)  number  is  Z-R701.  It  is 
government  non -classified  (Code  90). 

The  requested  version  level  (Code  H)  is  "As-Built" 

This  is  the  fourth  iteration  of  the  HL  segment  as  specified  by 
the  number  4.  Its  parent  is  HL  1.  The  hierarchical  level  is 
subassembly  (Code  U).  It  has  a  child  (Code  1). 

The  requested  drawing  (Code  DG)  number  is  12E2213.  It  is 
government  non -classified  (Code  90)  and  the  commercial 
protection  level  is  company  proprietary  (Code  06). 

The  latest  revision  (Code  E)  is  being  requested  (as  specified  by 
the  word  "Latest"). 


LIN*PD*Bracket  n/1  The  item  description  (Code  PD)  is  Bracket 

HL*5*4*I*0  n/1  This  b  the  fifth  iteration  of  the  HL  segment  as  specified  by  the 

numbers.  Its  parent  is  HL  4.  The  hierarchical  level  b  the 
item  (Code  I)-  It  has  no  child  (Code  0). 


SPI*90*ZZ*BM19285*Bill  of  Material  n/1  The  requested  item  number  (Code  ZZ)  b  BM19285  which  b  a 

bill  of  material  and  b  government  Don-classified  (Code  90). 


SE*29*0001  n/1 


This  transaction  set,  whose  control  number  b  0001,  contains 
29  segments. 


3.0.18 
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841  Specifications/Technical  Information 

This  Draft  Standard  for  Trial  Use  contains  the  format  and  establishes  the  data  contents  of  the 
Specifications/Technical  Information  Transaction  Set  (841)  for  use  within  the  context  of  an 
Electronic  Data  Interchange  (EDI)  environment  The  transaction  set  can  be  used  to  transmit 
specifications  or  technical  information  between  trading  partners.  It  can  be  used  to  allow  EDI 
trading  partners  the  ability  to  exchange  a  complete  or  partial  technical  descnption  of  a  product, 
process,  service,  etc.  over  the  same  path  as  any  other  EDI  transaction  The  detail  area  can 
include  graphic,  text,  parametric,  tabular,  image,  spectral,  or  audio  data  A  transmission  includes 
identification  information  to  assist  the  receiver  in  interpreting  and  utilizing  the  information 
included  in  the  transaction 

Further  action  as  a  consequence  of  the  receipt  and  initial  processing  of  the  specification  or  other 
technical  data  may  or  may  not  require  human  intervention  The  transmission  and  receipt  of  the 
data  may  require  pnvate  agreement  between  the  trading  partners  to  automate  the  receipt  of  the 
data. 

The  total  transaction  must  be  in  the  general  form  of  all  ASC  XI 2  transactions  so  that  an  EDI 
computer  system  will  be  able  to  automatically  recognize  it  as  a  Specification/Technical 
Information  Transaction  Set  and  pass  it  on  for  processing  of  the  data  itself.  The  transaction  set 
is  not  media  dependent. 

The  detail  area  of  the  Spec.ncation/Technical  Information  Transaction  Set  provides  a  structure 
which  allows  for  the  exchange  of  a  variety  of  specification  information.  For  example,  it  the 
transaction  contains  information  describing  a  complete  assembly,  it  would  be  necessary  to 
include  the  assembly  model,  the  models  for  each  of  the  individual  parts,  and  the  associated 
specifications  In  the  case  of  a  process  it  may  be  necessary  to  transmit  the  specification  of  the 
product  along  with  the  specifications  of  the  process  and  raw  materials  This  transaction  set  can 
also  be  linked  to  other  transaction  sets. 

This  transaction  set  is  not  limited  to  a  specific  transmission  protocol  and  uses  other  standards  as 
applicable  where  they  do  not  conflict  with  these  requirements  for  specification  transaction. 

Implementation  Notes 

1.  This  daft  implementation  convention  can  be  used  as  a  request  for  specifications/technical  information,  as 
follow-up  of  a  previous  request,  or  as  a  cancellation  of  a  previous  request. 

2.  A  trading  partner  can  use  this  841  convention  to  request  data  based  on  the  receipt  of  an  840  and  841 
transaction  set,  which  may  not  contain  all  the  required  specifications/technical  information  or  based  on  the 
need  for  updated  drawings. 

3.  Each  request  for  specificationsltechnical  information  must  be  submitted  as  an  individual  request  and 
should  contain  the  reference  number  of  the  solicitation,  contract  modification  number,  or  transaction  set 
reference  number  that  generated  the  need  for  the  request. 


Table  1 


SEG.  ID 

NAME 

REA  OES. 

MAX  USE 

LOOP  REPEAT 

ST 

Transaction  Set  Header 

M 

i 

SPI 

LOOP  ID -SR 

Specification  Identifier 

M 

i 

>1 

RDT 

Revision  Date/Time 

O 

>i 

NTE 

Note/Special  Instruction 

0 

>i 

XI 

Export  License 

o 

i 

X2 

Import  License 

0 

i 

X7 

Customs  Information 

0 

i 
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841  •  REQUEST 

N/U 

080 

GOV 

Military  Standard  1840-A  Record  Definition 

O 

>1 

LOOP10-SPI/REF 

>1 

9 

090 

REF 

Reference  Numbers 

O 

1 

10 

100 

DTM 

Date/Time  Reference 

0 

>1 

N/U 

110 

PER 

Administrative  Communications  Contact 

o 

>1 

LOOP  ID  -  SPt/NI 

>1 

11 

12u 

N1 

Name 

0 

1 

12 

130 

N2 

Additional  Name  Information 

O 

2 

13 

140 

N3 

Address  Information 

O 

2 

14 

150 

N4 

Geographic  Location 

O 

1 

N/U 

160 

REF 

Reference  Numbers 

O 

>1 

15 

170 

PER 

Administrative  Communications  Contact 

O 

>1 

Table  2 

PAGE*  POSH 

SEG.ID 

NAME 

REQ.  DES. 

MAX  USE 

LOOP  REPEAT 

'  _ 

LOOP  ID' HL 

16 

010 

HL 

Hierarchical  Level 

M 

1 

LOOP  ID  -  HL/SPl 

*1 

18 

020 

SPI 

Specification  Identifier 

O 

1 

20 

030 

RDT 

Revision  Date/Time 

O 

>1 

22 

040 

UN 

Item  Identification 

O 

1 

26 

045 

N1 

Name 

O 

*1 

27 

050 

MSG 

Message  Text 

O 

>1 

LOOPJD-HL/WD 

>1 

N/U 

060 

PID 

Product/Item  Description 

o 

1 

N/U 

065 

PKD 

Packaging  Description 

o 

>1 

N/U 

070 

QTY 

Quantity 

o 

>1 

N/U 

074 

MEA 

Measurements 

o 

>1 

N/U 

075 

UIT 

Unit  Detail 

o 

>1 

N/U 

076 

LOC 

Location 

o 

1 

N/U 

077 

PWK 

Paperwork 

o 

>1 

LOOPm>HUPfWPI«5 

N/U 

078 

PKG 

Marking,  Packaging.  Loading 

o 

1 

N/U 

079 

MEA 

Measurements 

o 

>1 

L0OPtD»HLfREF 

i  wm 

N/U 

080 

REF 

Reference  Numbers 

o 

1 

N/U 

090 

DTM 

Date/Time  Reference 

o 

>1 

N/U 

100 

PER 

Administrative  Communications  Contact 

o 

>1 

LOOP  ID  »  HULX 

*1 

N/U 

109 

LX 

Assigned  Number 

0 

1 

N/U 

110 

MEA 

Measurements 

0 

1 

N/U 

120 

DTM 

Date/Time  Reference 

o 

»1 

N/U 

130 

REF 

Reference  Numbers 

o 

>1 

LOOP  ID  •  HL/EF1 

N/U 

140 

EFI 

Electronic  Format  Identification 

0 

1 

N/U 

150 

GOV 

Military  Standard  1840-A  Record  Definition 

o 

>1 

N/U 

160 

BIN 

Binary  Data 

0 

>1 

LOOPID-HL/CID 

. >i 

N/U 

170 

CID 

Characteristic/Class  ID 

o 

1 

N/U 

180 

UIT 

Unit  Detail 

o 

1 
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N/U 

190 

TMD 

Test  Method 

0 

>1 

N/U 

200 

PSD 

Physical  Sample  Description 

0 

1 

N/U 

201 

CSS 

Conditional  Sampling  Sequence 

0 

1 

N/U 

210 

SPS 

Sampling  Parameters  for  Summary  Statistics 

0 

1 

N/U 

220 

MSG 

Message  Text 

0 

>1 

LOOP  ID  -  HUCID/M  EA 

>1 

N/U 

230 

MEA 

Measurements 

O 

1 

N/U 

240 

DTM 

Date/Time  Reference 

O 

>1 

N/U 

250 

REF 

Reference  Numbers 

O 

>1 

LOOPIO-HOCIO/STA 

*1 

N/U 

260 

STA 

Statistics 

O 

1 

N/U 

270 

DTM 

Date/Time  Reference 

O 

>1 

N/U 

280 

REF 

Reference  Numbers 

O 

>1 

LOOP  ID  •  HL/CIO/CSF 

>1 

N/U 

282 

CSF 

Conditional  Sampling  Frequency 

O 

1 

N/U 

283 

LS 

Loop  Header 

O 

1 

LOOP  10  •  HUCf  D/CSF/CfD 

>1 

N/U 

284 

CID 

Charactenstic/Class  ID 

O 

1 

N/U 

285 

MEA 

Measurements 

O 

1 

N/U 

286 

STA 

Statistics 

O 

1 

N/U 

287 

LE 

Loop  Trailer 

O 

1 

LOOPro.HUOIO/SH 

*1 

N/U 

290 

EFI 

Electronic  Format  Identification 

O 

1 

N/U 

300 

GOV 

Military  Standard  1840-A  Record  Definition 

O 

>1 

N/U 

310 

BIN 

Binary  Data 

O 

>1 

Table  3 

PAGE*  POS.«  SEG.ID  NAME _  REC.PES.  MAX  USE _ LOOP  REPEAT 

28  010  SE  Transaction  Sat  Trailer  M  1 

NOTES: 

2/010  To  be  meaningful,  at  least  one  of  the  SPI,  PID,  REF,  MEA,  EFI  or  CID  loops 
must  be  present  with  each  occurence  of  the  HL  loop. 

2/020  The  HL  segment  may  be  used  to  define  the  hierarchical  relationship  of  product-re¬ 
lated  specifications  reported  in  the  associated  HL  loop.  Product-related  specifica¬ 
tions  may  refer  to  the  product  in  its  entirety  or  to  subunits  of  the  product.  For 
example,  if  the  top  level  refers  to  an  assembly,  the  second-level  HL  segment 
may  refer  to  parts  or  subassemblies  of  the  top  assembly.  This  pattern  may  be 
repeated  as  often  as  required. 

2/170  The  CID  segment  may  be  used  to  define  either  a  general  class  of  properties, 
such  as  physical  properties,  or  an  individual  property  within  a  class.  The  CID 
loop  allows  the  user  the  ability  to  define  specifications  such  as  the  properties  of 
the  item  or  class,  the  environmental  conditions  under  which  the  specifications 
apply,  the  test  methods  to  be  used,  and  other  parameters  related  to  properties 
within  the  current  HL  hierarchical  level. 

2/201  The  sampling  sequence  specified  in  the  CSS  segment  will  take  precedence  over 
any  other  sampling  rate  (PSD03,  PSD09,  SPS06,  CSF02,  and  CSF03)  from  the 
point  the  CSS01  event  occurs  until  the  specified  sequence  is  completed. 
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2/201  If  no  other  sampling  is  specified,  then  only  the  sampling  indicated  in  this  segment 
is  performed  when  the  CSS01  event  occurs. 

2/282  The  sampling  rate  specified  is  the  CSF  segment.  It  would  take  precedence  over 
the  normal  sampling  rate  specified  in  PSD03  while  the  conditions  of  the  CSF  seg¬ 
ment  are  satisfied,  but  would  NOT  take  precedence  over  the  sampling  sequence 
activated  by  the  proposed  CSS  segment. 

2/282  If  no  other  sampling  rate  is  specified,  then  the  only  sampling  indicated  in  the  CSF 
segment  is  performed  while  the  CSF  conditions  are  met.  Sampling  will  cease 
when  the  conditions  are  no  longer  met. 

2/282  Conditional  values  specified  in  DE  740  (Range  Minimum)  will  be  interpreted  as 
“greater  than  or  equal  to  this  value."  Values  specified  in  DE  741  (Range  Maxi¬ 
mum)  will  be  interpreted  to  mean  “less  than  or  equal  to  this  value.” 

2/282  Repetitions  of  the  CSF  loop  allow  several  frequency  changes  (and  the  conditions 
that  would  trigger  those  changes)  to  be  specified. 

2/282  if  the  conditions  are  such  that  several  CSF  values  are  activated  at  the  same 
time,  the  value  with  the  highest  sampling  rate  shall  prevail. 

2/284  Either  the  MEA  segment  or  the  STA  segment  must  occur,  but  not  both. 

2/284  The  CID  loop  within  the  CSF  loop  is  used  to  specify  the  conditions  that  will  trig¬ 
ger  activation  of  the  conditional  value  in  the  CSF  segment. 

2/284  Repetitions  of  the  CID  loop  will  have  an  implied  logical  AND  between  the  condi¬ 
tions  set  in  each  iteration. 

2/285  The  elements  of  the  CID  segment  identify  the  conditional  property.  It  the  property 
is  a  measurement  from  within  the  manufacturing  process  of  a  plant  environment, 
rather  than  the  product,  the  segment  also  identifies  the  location  where  the  meas¬ 
urements  are  to  be  observed. 

2/286  If  the  condition  is  based  on  single  test  measurements,  the  MEA  segment  is  used 
to  specify  the  units  of  measure,  and  the  open  or  closed  numeric  range  of  the  con¬ 
ditional  test. 
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ST  •  TRANSACTION  SET  HEADER  ANSI  ASC  X12  VERSION/RELEASE  003030000 


Mandatory 


Segment:  ST  Transaction  Set  Header 
Level:  Header 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  indicate  the  start  of  a  transaction  set  and  to  assign  a  control  number 

Semantic:  The  transaction  set  identifier  (ST01 )  used  by  the  translation  routines  of 
the  interchange  partners  to  select  the  appropriate  transaction  set 
definition  (e.g.,  810  selects  the  invoice  transaction  set). 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

H£F  DATA 

ots. _ tiamn  mami _ «■— *imjrts 

ST01  143  Transaction  Set  Identifier  Code  M  ID  3/3 

Code  uniquely  identifying  a  Transaction  Set. 

841  XI  2.51  Specifications/Technical  Information 

ST02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

This  unique  control  number  is  assigned  by  the  originator  of  the  transaction  set  or  by  the  originator’s 
application  program.  This  same  number  is  carried  in  SE02. 
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Mandatory 


Segment:  SPI  Specification  identifier 
Level:  Header 
Loop:  SPI  Repeat:  >t 
Usage:  Mandatory 
Max  Use:  1 


841  •  REQUEST 
SPI  •  SPECIFICATION  IDENTIFIER 


Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


_ Data  Element  Summary _ _ 

HCF.  DATA 

DO-  AltMtKT  jjAMj _ ATTHO/TO 

SPI01  786  Security  Level  Code  M  ID  212 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  being  requested  have  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SP109. 

3.  If  die  data  being  requested  have  only  one  protection  requirement,  then  this  data  element  can  carry  either 
the  government  security  classification  code  or  the  commercial  security  protection  code. 

4.  Use  this  data  element  to  indicate  the  highest  protection  level  ( government  or  commercial )  assigned  to  the 
data  being  requested.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  protection  level  of  individual 
data  items. 


Mandatory 


Mandatory 


SPI02  128  Reference  Number  Qualifier  M  10  2/2 

Code  qualifying  the  Reference  Number. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

This  is  the  unique  reference  number  of  this  transaction  set. 


Not  Used 
Not  Used 
Not  Used 
Required 


SPI04 

790 

Entity  Title 

SPI05 

791 

Entity  Purpose 

SPI  06 

792 

Entity  Status  Code 

SPI07 

353 

Transaction  Set  Purpose  Code 

Code  identifying  purpose  of  transaction  set. 

Implementation  Note: 

Use  any  appropriate  listed  code. 


01  Cancellation 


0 

AN 

1/132 

0 

AN 

1/80 

0 

ID 

1/1 

0 

ID 

2/2 

DC18  *  JULY  9  1993 
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Code  Value  Implementation  Note: 

Use  Code  01  when  cancelling  a  request  for  specifications/lechnical  information.  When  Code  01  is 
used,  only  the  HL  segment  (HL01  and  HL03)  at  the  Detail  level  (Table  2)  is  needed. 

13  Request 

Code  Value  Implementation  Note: 

Use  Code  13  to  indicate  a  request  for  specifications/technical  information. 

45  Followup 

Code  Value  Implementation  Note: 

Use  Code  45  when  following  up  on  a  previous  request  for  specifications/technical  information. 
When  Code  45  is  used,  only  the  HL  segment  (HL01  and  HL03)  at  the  Detail  level  (Table  2)  is 
needed. 


Optional 


Optional 


Not  Uaad 
Not  Used 
Not  Used 


SPI08  755  Report  Type  Code  O  ID  212 

Code  indicating  the  title  or  contents  of  a  document,  report  or  supporting  item 

Implementation  Note: 

Any  code  may  be  used  but  typically  Code  DW  and  Code  SP  are  used. 

SPI09  786  Security  Level  Code  O  ID  212 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  this  data  element  ONLY  when  SPI01  is  Code  90,  92,  93,  94,  or  99,  and  the  data  item  being  requested 
also  has  a  commercial  security  protection  requirement. 

2.  Use  this  data  element  to  indicate  the  highest  level  of  commercial  security  protection  assigned  to  the  data 
being  requested  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  commercial  security  protection  of 
individual  data  items. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

212 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

o 

NO 

1/6 
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NTE  •  NOTE/SPECIAL  INSTRUCTION 


Optional 


Segment:  NTE  Note/Speciai  Instruction 
Level:  Header 
Loop:  SPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  transmit  information  in  a  free-fonn  format,  if  necessary,  for  comment 
or  special  instruction 

Comment:  The  NTE  segment  permits  free-form  information/data  which,  under  ANSI 
XI 2  standard  implementations,  is  not  machine  processable.  The  use  of 
the  "NTE"  segment  should  therefore  be  avoided,  if  at  all  possible,  in  an 
automated  environment. 

Implementation  Note: 

Use  this  segment  to  provde  information  pertinent  to  the  entire  transaction  set.  To  provide 
information  relative  to  a  specific  data  item,  use  the  MSG  segment  in  Table  2. 


Optional 


Data  Element  Summa 


data 

ELEMENT  NAME 


NTE01 


363  Note  Reference  Code  O  ID  3/3 

Code  identifying  the  functional  area  or  purpose  for  which  the  note  applies. 

GEN  Entire  Transaction  Set 
Code  Value  Implementation  Note: 

Use  Code  GEN  for  any  notes  that  relate  to  the  entire  transaction  set. 


Mandatory 


NTE02 


Free  Form  Message 

Free-form  text. 


M  AN  1/60 


DC18  •  JULY  9  1993 
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Optional 


Segment:  REF  Reference  Numbers 
Level:  Header 

Loop:  S PI/REF  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  identifying  numbers. 

Syntax:  R0203  —  At  least  one  of  REF02  or  REF03  is  required. 


Implementation  Note: 

This  REF  segment  should  be  used  to  provide  appropriate  reference  numbers  relative  to  this  request 
for  data. 


Mandatory 


Conditional 


Not  Used 


_ Data  Element  Summary _ 

HEF  DATA 

PES _ ELEMENT  NAME _ ATTAIPl/TES 

REF01  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

C4  Change  Number 
Code  Value  Implementation  Note: 

Use  Code  C4  for  the  contract  modification  number  to  which  the  data  being  requested  pertain. 

CT  Contract  Number 

Code  Value  Implementation  Note: 

Use  Code  CT  for  the  contract  number  to  which  the  data  being  requested  pertain. 

KS  Solicitation 

Code  Value  Implementation  Note: 

Use  Code  KS  for  the  solicitation  number  which  referenced  the  data  being  requested. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  7Z  for  the  unique  reference  number  of  the  transaction  set  to  which  the  data  in  this 
transaction  set  pertain. 

REF02  127  Reference  Number  C  AN  1/30 

Reference  number  or  identification  number  as  defined  .or  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

REF03  352  Description  C  AN  1/80 
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Optional 


Segment:  DTM  Date/Time  Reference 
Level:  Header 
Loop:  SPI/REF 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  specify  pertinent  dates  and  times 
Syntax:  R0203  —  At  least  one  of  DTM02  or  DTM03  is  required. 


Mandatory 


Conditional 


Not  Used 
Not  Used 
Not  Used 


_ Df-a  Element  Summary _ 

RIF  DATA 

PIS _ ILHtHT  KAMI _ ATTTtf  LTTiS 

DTM01  374  Date/Tima  Qualifier  M  ID  3/3 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

092  Contract  Effective 
Code  Value  Implementation  Note: 

When  REF01  is  Code  CT,  use  Code  092  to  indicate  the  date  of  the  contract  specified  in  REF02. 

097  Transaction  Creation 
Code  Value  Implementation  Note: 

When  REF0I  is  Code  TN,  use  Code  097  to  indicate  the  creation  date  of  this  transaction  set. 

152  Effective  Date  of  Change 
Code  Value  Implementation  Note: 

When  REF01  is  Code  C4.  use  Code  152  to  indicate  the  date  of  the  contract  modification  specified 
inREF02. 

368  Submittal 

Code  Value  Implementation  Note: 

When  REF01  is  Code  ZZ,  use  Code  36S  to  indicate  the  date  of  the  referenced  transaction  set 
specified  in  REF 02  ■ 

993  Request  for  Quotation 

Code  Value  Implementation  Note: 

When  REF0I  is  Code  KS,  use  Code  993  to  indicate  the  date  of  the  solicitation  specified  in  REF 02 


DTM02 

373 

Date 

Date  (YYMMDD). 

C 

DT 

6/6 

DTM03 

337 

Time 

C 

TM 

4/6 

DTM04 

623 

Time  Code 

O 

ID 

2/2 

DTM05 

624 

Century 

0 

NO 

2/2 

0C18  •  JULY  9  1993 


10 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REQUEST 
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Segment:  N1  Name 
Level:  Header 
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Optional 


Loop:  SPI/N1  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 
Syntax:  1.  R0203  —  At  least  one  of  N102  or  N103  is  required. 

2.  P0304  —  If  either  Nf  03  or  N104  is  present,  then  the  other  is  required 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  Key  to  the  table  maintained  by  the 
transaction  processing  party. 


Implementation  Note: 

Whenever  possible,  idem ificai ion  and  address  information  should  be  provided  using  of  N101 , 
N103,  and  N104.  Use  N102  and  segmems  N2  through  N4  when  this  information  cannot  be 
provided  by  use  of  a  CAGE  code  or  a  DoDAAC. 


Mandatory 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

REF.  DAT* 

PES. _ ELEMENT  HAKE  _ _ _ ATTROUTES 

NlOi  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

BY  Buying  Party  (Purchaser) 

Code  Value  Implementation  Note: 

Use  Code  BY  to  indicate  the  buying  party. 

FR  Message  From 
Code  Value  Implementation  Note: 

Use  Code  FR  to  indicate  the  emity  sending  the  message. 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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DEPARTMENT  OP  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  AS C  X12  VERSION/RELEASE  003030DOD 


841  •  REQUEST 
N2  •  ADDITIONAL  NAME  INFORMATION 


Optional 


Segment:  N2  Additional  Name  Information 
Level:  Header 
Loop:  SPI/N1 
Usage:  OptJnal 
Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 
Implementation  Note: 

Use  of  Ms  segment  is  not  necessary  when  the  entity  cited  in  N101  is  described  by  use  of  a  CAGE 
code  or  a  DoDAAC. 


Mandatory 

Optional 


Data  Element  Summary 


WF 

DES. 

DATA 

ELEMENT 

NAME 

ATTfUSUTES 

N201 

93 

Name 

Free-form  name. 

M 

AN 

1/35 

N202 

93 

Name 

Free-form  name. 

O 

AN 

1/35 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REQUEST 

N3  •  ADDRESS  INFORMATION  ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


Optional 


Segment:  N3  Address  Information 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  2 


Purpose:  To  specify  the  location  of  the  named  party 

Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  entity  cited  in  N 1 01  is  described  by  use  of  a  CAGE 
code  or  a  DoDAAC. 


Mandatory 


Optional 


Data  Element  Summary 


*EF. 

OES 

DATA 

ELEMENT 

NAME 

ATTRIBUTES 

N301 

166 

Address  Information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN 

1/35 
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DRAFT  IMPLEMENTATION  CONVENTION 


Ml  •  REQUEST 
N4  •  GEOGRAPHIC  LOCATION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


Optional 


Conditional 

Optional 

Optional 

Optional 

Conditional 

Conditional 


Segment:  N4  Geographic  Location 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  the  geographic  place  of  the  named  party 

Syntax:  1.  R0105  —  At  least  one  of  N401  or  N405  is  required. 

2.  P0506  —  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

Comments:  1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401)  is  in  the  USA  or  Canada. 

Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  entity  cited  in  N101  is  described  by  use  of  a  CAGE 
code  or  a  DoDAAC. 


Data  Element  Summai 


REF. 

DCS. 

OATA 

CLEMENT 

NAME 

ATTRIBUTES 

N401 

19 

City  Name 

Free-form  text  for  city  name. 

C 

AN  2/30 

N402 

156 

State  or  Province  Code  O  ID  2/2 

Cot  e  (Standard  State/Province)  as  defined  by  appropriate  government  agency. 

N403 

116 

Postal  Code  O  ID  3/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

N404 

26 

Country  Code 

Code  identifying  the  country. 

O 

ID  2/3 

N405 

309 

Location  Qualifier 

Code  identifying  type  of  location. 

c 

ID  1/2 

N406 

310 

Location  Identifier 

Code  which  identifies  a  specific  location. 

c 

AN  1/25 
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DEPARTMENT  OP  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 

841  •  REQUEST 

PER  •  ADMINISTRATIVE  COMMUNICATIONS  CONTACT  ANSI  ASC  X12  VERSION/RELEASE  0Q303QDOD 


Optional 


Segment:  PER  Administrative  Communications  Contact 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  person  or  office  to  whom  administrative  communications 
should  be  directed 

Syntax:  1.  P0304  —  If  either  PER03  or  PER04  is  present,  then  the  other  is 
required. 

2.  P0506  —  If  either  PER05  or  PER06  is  present,  then  the  other  is 
required. 


Mandatory 


Optional 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

Sis.  CLEMENT  NAME _ ATTWUTtS 

PER01  366  Contact  Function  Code  M  ID  2/2 

Code  identifying  the  major  duty  or  responsibility  of  the  person  or  group  named. 

1C  Information  Contact 
Code  Value  Implementation  Note: 

Use  Code  1C  to  indicate  the  requester's  point  of  contact. 

PER02  93  Name  O  AN  1/35 

Free-form  name. 

Implementation  Note: 

Use  to  provide  the  name  of  the  point  of  contact. 

PER03  365  Communication  Number  Qualifier  C  ID  2/2 

Code  identifying  the  type  of  communication  number. 

Implementation  Note: 

Use  any  appropriate  code  although  Code  EM  is  preferred. 

EM  Electronic  Mail 
FX  Facsimile 
TE  Telephone 
TM  Telemail 

PER04  364  Communication  Number  C  AN  1/25 

Complete  communications  number  including  country  or  area  code  when 
applicable. 

PER05  365  Communication  Number  Qualifier  C  ID  2/2 

Code  identifying  the  type  of  communication  number. 


Conditional 


PER06 


364 


Communication  Number  C  AN 

Complete  communications  number  including  country  or  area  code  when 
applicable. 


1/25 
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DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD__ 


Ml  •  REQUEST 
HL  •  HIERARCHICAL  LEVEL 


Mandatory 


Segment:  HL  Hierarchical  Level 
Level:  Detail 
Loop:  HL  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 


Purpose:  To  identify  dependencies  among  ana  tne  content  of  hierarchically  related 
groups  of  data  segments. 

Comments:  1.  The  HL  Segment  is  used  to  identify  levels  of  detail  information  using  a 
Hierarchical  Structure,  such  as  relating  line  item  data  to  shipment  data, 
and  packaging  data  to  line  item  data. 

2.  The  HL  segment  defines  a  top-down/left-right  ordered  structure. 

3.  HL01  shall  contain  a  unique  alphanumeric  number  for  each 
occurrence  of  the  HL  segment  in  the  transaction  set.  For  example  HL01 
could  be  used  to  indicate  the  number  of  occurrences  of  the  HL  segment, 
in  which  case  the  value  of  HL01  would  be  "1"  for  the  initial  HL  segment, 
and  would  be  incremented  by  one  in  each  subsequent  HL  segment 
within  the  transaction. 

4.  HL02  identifies  the  Hierarchical  ID  Number  of  the  HL  segment  to 
which  the  current  HL  segment  is  subordinate. 

5.  HL03  indicates  the  context  of  the  series  of  segments  following  the 
current  HL  segment  up  to  the  next  occurrence  of  an  HL  segment  in  the 
transaction.  For  example,  HL03  is  used  to  indicate  that  subsequent 
segments  in  the  HL  loop  form  a  logical  grouping  of  data  referring  to 
shipment,  order  or  item  level  information. 

6.  HL04  indicates  whether  or  not  there  are  subordinate  (or  child)  HL 
segments  related  to  the  current  HL  segment. 


Implementation  Notes: 

1.  When  requesting  a  single  specification  or  item  of  technical  information,  only  one  iteration  of  the 
HL  loop  is  necessary. 


2.  When  requesting  multiple  items  that  may  or  may  not  have  a  hierarchical  relationship,  repeat  the 
HL  loop  as  many  times  as  required  to  specify  all  levels  and  use  as  many  iterations  of  the  HL/SPl 
loop  as  necessary. 

3.  When  SPI07  is  Code  01  (cancellation)  or  Code  45  (follow-up)  the  ONLY  entries  in  the  Detail 
level  (Table  2)  are  in  HL01  and  HL03. 


Mandatory 


_ Data  Element  Summary _ 

REF.  DATA 

PES.  ELEMENT  NAME  _ ATTRIBUTES 

HL01  628  Hierarchical  ID  Number  M  AN  1/12 

A  unique  number  assigned  by  the  sender  to  identify  a  particular  data  segment  in 
a  hierarchical  structure. 

Implementation  Note: 

This  is  a  unique  and  progressive  number  assigned  by  the  originator  of  the  transaction  set  starling  with  the 
number  1. 
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DEPARTMENT  Of  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REQUEST 

HL  •  HIERARCHICAL  LEVEL 


Optional 


HL02  734 


_ ANSI  ASC  X12  VERSION/RELEASE  003030DQD 

Hierarchical  Parent  ID  Number  O  AN  1/12 

Identification  number  of  the  next  higher  hierarchical  data  segment  that  the  data 
segment  being  described  is  subordinate  to. 


Implementation  Note: 

This  data  element  is  used  only  when  requesting  multiple  specifications  or  items  of  technical  information  that 
have  a  hierarchical  relationship. 


Mandatory 


HL03  735  Hierarchical  Level  Code  M  ID  1/2 

Code  defining  the  cnaracteristic  of  a  level  in  a  hierarchical  structurs. 

Implementation  Note: 

Use  any  appropriate  listed  codes  to  indicate  the  hierarchical  relationship  of  the  data  being  requested. 


A  Assembly 
F  Component 
I  Item 

Code  Value  Implementation  Note: 

Use  Code  I  as  a  default  code  when  no  other  code  is  applicable. 


SY  System 
U  Subassembly 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  72  only  when  SPI07  is  either  Code  45  or  Code  01.  This  is  required  to  comply  with  the 
mandatory  nature  of  this  data  element. 


Optional 


HL04  736  Hierarchical  Child  Code  O  ID  l/l 

Code  indicating  whether  if  there  are  hierarchical  child  data  segments  subordinate 
to  the  level  being  described. 

Implementation  Note: 

When  requesting  single  or  multiple  specifications! technical  information  that  have  no  hierarchial  relationship, 
no  entry  is  required. 

0  No  Subordinate  HL  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  0  to  indicate  the  lowest  level  in  a  hierarchical  relationship. 

1  Additional  Subordinate  HL  Data  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  I  to  indicate  there  are  lower  level  items  in  the  hierarchical  relationship. 
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DEPARTMENT  OP  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD_ 


Ml  •  REQUEST 
SPI  •  SPECIFICATION  IDENTIFIER 


Optional 


Mandatory 


Mandatory 


Mandatory 


Optional 


Segment:  SPI  Specification  Identifier 
Level:  Detail 

Loop:  HUSPI  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 

Data  Element  Summa 


REF.  DAT* 

015.  ELEMENT  NAME  _ _ ATTRMMJTES 


SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  item  being  requested  has  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classification  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  item  being  requested  has  only  one  protection  requirement,  then  this  data  element  can  carry 
either  the  government  security  classification  or  the  commercial  security  protection  code. 


M  ID 


SPI02  128  Reference  Number  Qualifier  M  ID 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

Any  code  can  be  used  but  the  following  codes  are  typically  used: 

DD  Document  Identification  Code 
Code  Value  Implementation  Note: 

Use  Code  DD  for  the  reference  number  of  an  Engineering  Data  List. 

DG  Drawing  Number 

QC  Product  Specification  Document  Number 

51  Engineering  Specification  Number 

52  Military  Specification  Number  (MILSPEC) 

53  Specification  Number 

TP  Test  Specification  Number 
W9  Special  Packaging  Instruction  Number 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  7Z  for  another  type  of  reference  number  and  identify  that  number  in  SPI04. 

SPI03  127  Reference  Number  M  AN 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 


SPI04  790  Entity  Title 

Title  of  the  data  entity. 


O  AN  1/132 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


641  •  REQUEST 

SPI  •  SPECIFICATION  IDENTIFIER  ANSI  ASC  XI 2  VERSION/RELEASE  003030DOD_ 


Not  Used 
Optional 


Not  Used 
Not  Usad 
Optional 


Not  Usad 
Not  Usad 
Not  Usad 


Implementation  Note: 

When  SP102  is  Code  7Z,  identify  the  reference  number  cited  in  SPI03. 

SPI05  791  Entity  Purpose  0  AN  1/80 

SPI06  792  Entity  Status  Code  O  ID  1/1 

Code  indicating  the  current  status  of  the  data  item  specified  by  the  electronic 
data  item. 

Implementation  Note: 

Use  any  code. 

2  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  Z for  another  entity  statw  condition  and  explain  in  the  MSG  segment. 


SPI07 

353 

Transaction  Set  Purpose  Code 

O 

ID 

2/2 

SPI08 

755 

Report  Type  Code 

O 

ID 

2/2 

SPI09 

786 

Security  Level  Code 

0 

ID 

2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 


Implementation  Note: 

Use  this  data  element  ONLY  when  SPI01  is  Code  90,  92,  93,  94,  or  99.  and  the  data  item  being  requested 
also  has  a  commercial  security  protection  requirement. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (T rading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

2/2 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

o 

NO 

1/6 
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ANSI  ASCX12  VERSION/RELEASE  003030DOD.  RDT  •  REVISION  DATETIME 


Optional 


Optional 


Conditional 


Optional 


Conditional 
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DEPARTMENT  Of  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


RDT .  REVISION  DATE/TIME _ _ _ ANSI  ASC  X12  VERSION/RELEASE  00303000D 

Implementation  Note: 

Enter  the  date  of  the  change,  revision,  or  version  being  requested 


NotUsad 
Not  Used 


RDT05 

337 

Time 

RDT06 

623 

Time  Code 

C  TM  4/6 
O  ID  2/2 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  003030DOD 


841  •  REQUEST 
UN  •  ITEM  IDENTIFICATION 


Optional 


Not  Used 
Mandatory 


Segment:  LIN  Item  identification 
Level:  Detail 
Loop:  HL/SPI 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  basic  item  identification  data 
Syntax:  1.  C0405  —  If  LIN04  is  present,  then  LIN05  is  required. 

2.  C0607  —  If  LIN06  is  present,  then  LIN07  is  required. 

3.  C0809  —  If  LIN08  is  present,  then  LIN09  is  required. 

4.  Cl  01 1  —  If  LIN10  is  present,  then  LIN1 1  is  required. 

5.  C1213  —  If  LIN12  is  present,  then  LIN13  is  required 

6.  Cl 41 5  —  If  LIN14  is  present,  then  LIN15  is  required. 

7.  Cl 61 7  —  If  LIN16  is  present,  then  LIN17  is  required. 

8.  C1819  —  If  LIN18  is  present,  then  LIN19  is  required. 

9.  C2021  —  If  LIN20  is  present,  then  LIN21  is  required. 

10.  C2223  —  If  LIN22  is  present,  then  LIN23  is  required. 

11.  C2425  —  If  LIN24  is  present,  then  LIN25  is  required. 

12.  C2627  —  If  LIN26  is  present,  then  LIN27  is  required. 

13.  C2829  —  If  LIN28  is  present,  then  LIN29  is  required. 

14.  C3031  —  If  LIN30  is  present,  then  LIN31  is  required. 

Semantic:  LIN01  is  the  line  item  identification 

Comments:  1.  See  the  Data  Dictionary  for  a  complete  list  of  ID's. 

2.  LIN02  through  LIN31  provide  for  fifteen  (15)  different  product/service 
ID  s  for  each  item.  For  Example:  Case,  Color,  Drawing  No.,  UPC  No., 
ISBN  No.,  Model  No.,  SKU. 

Implementation  Notes : 

1.  Use  this  segment  to  transmit  information  relative  to  the  requested  data  item  identified  in  SPI03. 

2.  LIN02  through  UN31  are  used  in  pairs  (i.e.,  UN02  and  L1N03)  as  required  to  carry  additional 
information  related  to  the  specific  data  item  identified  in  SPI03. 

_ Data  Element  Summary _ 


015 


DATA 

ItBIPIT  NAME 


LIN01 

LIN02 


350  Assigned  identification  O 

235  Product/Service  ID  Qualifier  M 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

F7  End-Item  Description 
Code  Value  Implementation  Note: 

Use  Code  F7  for  the  application  reference  from  an  Engineering  Data  List. 


AN 

ID 


1/11 

2/2 
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DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REQUEST 

UN  -  ITEM  IDENTIFICATION 


ANSI  ASC  XI 2  VERSION/RELEASE  003030DOD 


Mandatory 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 


FS  National  Stock  Number 

Code  Value  Implementation  Note: 

Use  Code  FS  for  ihe  National  Stock  Number 

IN  Buyer's  Item  Number 
Code  Value  Implementation  Note: 

Use  Code  IN  for  the  CLIN  or  SUBLLIN. 

MG  Manufacturer  s  Part  Number 

Code  Value  Implementation  Note: 

Use  Code  MG  for  a  manufacturer  s  part  number. 


PD  Par*  Number  Description 

Code  Value  Implementation  Note: 

Use  Code  PD  for  the  noun  description  of  the  requested  data  item 


LIN03 

234 

Product/Service  ID  M 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

LIN04 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

LIN05 

234 

Product/Service  ID  c 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

LINOS 

235 

Product/Service  ID  Qualifier  ° 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
ProducVServtce  ID  (234). 

ID 

2/2 

LIN07 

234 

Product/Service  ID  c 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

LINOS 

235 

Product/Service  ID  Qualifier  ° 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

LIN09 

234 

Product/Service  ID  C 

Identifying  number  for  a  prcduct  or  service. 

AN 

1/30 

LIN10 

235 

Product/ Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

LIN11 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

LIN12 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

LIN13 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

LIN14 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 
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- -  Ml  •  REQUEST 

ANSI  ASC  X12  VERSION  RELEASE  003030DOD_  _  UN  •  ITEM  IDENTIFICATION 


Conditional 

LIN  15 

234 

Product/Service  ID  c 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN16 

235 

Product/Service  10  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN17 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN18 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN  19 

234 

Product'Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN20 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN21 

234 

Product'Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN22 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

| 

LIN23 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

t 

LIN24 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product'Service  ID  (234). 

ID 

2/2 

Conditional 

LIN25 

234 

Product'Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN26 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN27 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN28 

23b 

Product'Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product'Service  ID  (234). 

ID 

2/2 

Conditional 

LIN29 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN30 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN31 

234 

Product/Service  ID  C 

AN 

1/30 
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ANSI  ASC  X12  VERSION/RELEASE  003030DQD 

Segment:  N1  Name 
Level:  Detail 


Ml • REQUEST 
N1 -NAME 


Optional 


Loop:  HUSPI 
Usage-  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N103  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Mandatory 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

MF.  DATA 

Ots.  tlBMMT  WAKE _ ATTIMDUTP 

N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

ZE  End  Item  Manufacturer 

Code  Value  Implementation  Note: 

Use  Code  ZE  to  identify  the  manufacturer  of  an  item. 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 


N104  67  Identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 


DC18  •  JULY  9  1993 


26 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REQUEST 
MSG  •  MESSAGE  TEXT 


Optional 


Segment:  MSG  Message  Text 
Level:  Detail 
Loop:  HUSPI 
Usage:  Optional 
Max  Use:  >1 


ANSI  ASC  XI 2  VERSION/RELEASE  003030DOD 


Purpose:  To  provide  a  free  form  format  that  would  allow  the  transmission  of  text 
information. 

Comment:  MSG02  is  not  related  to  the  specific  characteristics  of  a  printer,  but 
identifies  top  of  page,  advance  a  line,  etc. 

Implementation  Notes: 

1.  Use  this  segment  to  transmit  information  relative  to  a  specific  data  item. 

2.  Maximum  use  is  3 . 


Mandatory 

Optional 


Data  Element  Summary 

REF. 

DES. 

DATA 

ELEMENT 

NAME 

ATTWRV/TES 

MSG01 

933 

Free-Form  Message  Text 

Free-form  message  text. 

M  AN  1/264 

MSG02 

934 

Printer  Carriage  Control  Code 

O  ID  2/2 

A  field  to  be  used  for  the  control  of  the  line  feed  of  the  receiving  printer. 
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Ml  •  REQUEST 

ANSI  ASC  X12  VERSION/RELEASE  003030PQD_ _ SE  •  TRANSACTION  SET  TRAILER 

Segment:  SE  Transaction  Set  Trailer 
Level:  Summary 


Mandatory 


Loop: 
Usage: 
Max  Use: 
Purpose: 

Comment: 


Mandatory 

1 

To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

SE  is  the  last  segment  of  each  transaction  set. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

MP.  DAT* 

PIS  IIPMHT  WAKE _ _ _ ATTTMPUTtS 

SE01  96  Number  of  included  Segments  M  NO  1/10 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 

SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

Enter  the  same  number  as  carried  in  ST02. 
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4.0  ASC  X  12  FORMS 

In  this  chapter,  applicable  ASC  X12  forms  are  presented. 
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DEPARTMENT  OF  DEFENSE 
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DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


flav  9/14/92 

Date  Submitted _ _ _  DM  NUMBER _ 

(Submitter  Provide)  (Secretariat  Only) 

ASC  XI 2 

WORK  REQUEST  FORM 


A.  SUBMITTER  INFORMATION: 

Subminer  Name _ _ Company  ___________________ 

Address  _ _  Address /ZIP  _ /ZIP  *4 

Phone  _ _ 


Submission  represents  the  position  of: _ SC  Chair  Initials: 


B.  REFERENCE  USED:  Version _ /Release _ /Subrelease _ or  WorVbook  (date) 


C.  RAMIFICATIONS: 

Transaction  Set(s)  Used 
Segment(s)  Affected 
Data  Bement(s)  Affected 
Other  Standard(s) 


D.  BUSINESS  CASE/REASON  FOR  CHANGE: 


E.  PROPOSED  WORK: 
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Am.  9/14/92 

WR  Form  Pag#  Two  DM  NUMBER 

(Secretariat  Only) 

FORM  FOR  NEW  OR  REVISED  CODE  SOURCE  REFERENCE 
FOR  X12.3  DATA  ELEMENT  DICTIONARY 

INSTRUCTIONS:  Complete  this  form  whenever  a  new  data  element  or  data  element  code  Is  requested  to  be 
added  to  Appendix  A  of  X  72. 3  Oata  Element  Dictionary,  which  references  a  code  list  published  by  an  organization 
external  to  XI 2.  Use  one  form  for  each  new  reference.  This  form  may  be  used  to  revise  current  references:  fit  out 
the  appropriate  areas  below. 

PART  1:  REFERENCE  Cirdt  i  or  2  baiow.  if  2.  fill  in  tna  blank. 

(1)  NEW  REFERENCE 

(2)  REVISED  REFERENCE,  Current  reference  number/name _ 

PART  2:  REFERENCE  TITLE  ifthere  «  only  on#  aouroe  for  oodea  for  (ha  data  alemant  the  «•  mould  ba  the  uma  m  the  data 
•la mam  name.  If  there  ara  multiple  ooOaa  referencing  axtamal  coda  aoureaa  for  the  aame  data  atamant  tma  ahouM  approdmaaa  eta  code 
dafinition. 

REFERENCE  TITLE: 

PART  3:  DATA  ELEMENTS  USED  IN  Give  the  data  atamant  reference  numbar  and  nama  which  directa  tha  uaar  to  thia  ooda 
souroa.  Giva  tha  ooda  10  (H  aaalgned)  If  thia  la  for  a  apaciflc  cede  at  the  data  alemant 

USED  IN:  DENo. _ .Code  ID _ 

PART  4:  SOURCE  Provide  tha  nama  of  tha  publication  which  contain*  the  codec  referenced. 

PUBLISHED  IN: 

PARTS:  AVAILABLE  FROM  Give  the  publiaher,  or  other  contact  from  whom  the  uaer  oan  obtain  the  document. 

AVAILABLE:  Name/Attn  of  _ 

Company  _ _ 

Address  _ 

Address  _ 

Address /ZIP  _ /ZIP  *  4 _ 


PART  6:  ABSTRACT  Briefly  describe  die  publication,  ita  purpose,  and  Indict*  what  eodaa  It  eontalna. 
ABSTRACT: 
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5.0  GLOSSARY 


This  chapter  contains  A  SC  X12-  and  DoD-specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 

ANSI  Standard 

A  document  published  by  ANSI  that  has  been  approved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
such  standards  must  have  been  developed  by  an  ANSI  committee 
and  must  be  revisited  by  that  committee  within  5  years  for  updat¬ 
ing.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

A  predefined  area  within  a  transaction  set  (header,  detail,  sum¬ 
mary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  XI 2.  It  comprises  industry 
members  who  create  electronic  data  interchange  (EDI)  standards 
for  submission  to  ANSI  for  subsequent  approval  and  dissemination. 

Authentication 

A  mechanism  that  allows  the  receiver  of  an  electronic  transmission 
to  verify  the  sender  and  the  integrity  of  the  content  of  the  trans¬ 
mission  through  the  use  of  an  electronic  “key”  or  algorithm  shared 
by  the  trading  partners.  That  algorithm  is  sometimes  referred  to 
as  an  electronic  signature. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditional  (C) 

A  data  element  requirement  designator  that  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  segment  that  has  the  same  structure  as  a  data  segment  but  is 
used  for  transferring  control  information  for  grouping  data  seg¬ 
ments.  Control  segments  may  be  loop  control  segments  (LS/LE), 
transaction  set  control  segments  (ST/SE),  or  functional  group  con¬ 
trol  segments  (GS/GE),  defined  in  XI 2.6,  or  interchange  control 
segments  (ISA/IEA/TA1)  defined  in  X12.5. 
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Data  Element 

The  basic  unit  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  It  may  be  single-char¬ 
acter  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

The  range,  minimum  to  maximum,  of  the  number  of  character 
positions  available  to  represent  the  value  of  a  data  element.  A 
data  element  may  be  of  variable  length  and  range  from  minimum 
to  maximum  or  it  may  be  of  fixed  length  in  which  the  minimum 
is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Number  assigned  to  each  data  element  as  a  unique  identifier. 
Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  appear  in  the 
segment  if  the  segment  is  transmitted.  The  XI 2  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  consider 
a  segment  “mandatory”  even  through  it  is  “optional"  by  X12 
standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment.  DoD  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types:  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

Two  levels  of  separators  and  a  terminator.  The  delimiters  are  an 
integral  part  of  the  transferred  data  stream.  They  are  specified  in 
the  interchange  header  and  may  not  be  used  in  a  data  element 
value  elsewhere  in  the  interchange.  From  highest  to  lowest  level, 
the  separators  and  terminator  are  segment  terminator  and  data 
element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  to  serve  as  the  Secretariat  for  XI 2. 

DSTL 

Draft  Standard  for  Trial  Use.  It  represents  a  document  approved 
for  publication  by  the  full  X12  committee  following  membership 
consensus  and  subsequent  resolution  of  negative  votes.  (Final 
Report  of  XI 2  Publications  Task  Group).  The  Draft  EDI  Standard 
for  Trial  Use  document  represents  an  ASC  X12  approved  standard 
for  use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 
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EDI 

Electronic  data  interchange.  The  computer-application-to-com- 
puter-appiication  exchange  of  business  information  in  a  standard 
format. 

Electronic  Envelope 

Electronic  information  that  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sender  to  one  receiver. 

Element  Delimiter 

A  single-character  that  follows  the  segment  identifier  and  separates 
each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments  (GS/GE) 

These  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  implement  XI 2  stand¬ 
ards. 

Interchange  Control  Segments  (ISA/IEA) 

These  segments  identify  a  unique  interchange  being  sent  from  one 
sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Structure 

The  interchange  header  and  trailer  segments  that  envelop  one  or 
more  functional  groups  or  interchange-related  control  segments  and 
perform  the  following  functions:  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  Segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element's  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  elementAegment  is  at  the  option  of 
the  sending  party  and  can  be  based  on  the  mutual  agreement  of 
the  interchange  parties. 

Qualifier 

A  data  element  that  identifies  or  defines  a  related  element,  set  of 
elements,  or  a  segment.  The  qualifier  contains  a  code  taken  from 
a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  that  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  segment,  consisting  of  a  combination  of 
two  or  three  upper-casr  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  It  is  not  a 
data  element.  The  segment  identifier  in  EDIFACT  is  a  component 
data  element  —  part  of  a  composite  data  element  consisting  of  a 
segment  identifier  and  an  explicit  looping  designator. 


BASELINE  AS  OF:  JULY  9,1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 

Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  that  define  the  structure  of  the  EDI  standards 
(i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are  published 
in  ANSI  X12.6. 

Transaction  Set 

A  document  that  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
header  segment,  one  or  more  data  segments  in  a  specified  order, 
and  a  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  data  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  XI 2  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

VICS  Committee 

Voluntary  Interindustry  Communications  Standards  for  EDI. 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  EDI. 

X12.5 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  structure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  transaction  sets, 
and  groups  of  related  transaction  sets. 
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5.2  DoD  GLOSSARY 

AIS 

Automated  information  systems 
DVSD  (Logistics) 

Deputy  Under  Secretary  of  Defense  (Logistics) 

DES 

Data  encryption  standard 
DISA 

Defense  Information  Systems  Agency 

DLA 

Defense  Logistics  Agency 
ISA 

Interchange  control  header  identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  identifier 
PLUS 

Protection  of  logistics  unclassified/sensitive  systems 
UN/EDIFACT 

EDIFACT;  electronic  data  interchange  for  administration,  com¬ 
merce,  and  transport 

USD  (A  &  T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 
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